Despite the fact that Lisex 0.0 is only a prototype, it shares many qualities with a final version: the security model has been formally specified and verified and functional testing based on the formal model was used to some extent; this prototype includes a MLS model and extended DAC features, etc. However, because this is only a prototype, many features were developed without performance in mind, either incomplete or inconvenient.

Software and Installation

Manual del usuario y del administrador

Programmer's Reference Guide

Lisex 0.0 is, in principle, compatible with Linux. More precisely, Lisex 0.0 adds some kernel calls to the system which are no necessary made to be used by other components, and those kernel call that have been modified (for instance, open, creat, etc.) have the same signature, i.e. they have the same parameters and return values as the original ones.

However, the modified system calls are not semantically compatible; in some sense, the compatibility is broken if we also consider that the behavior of the modified kernel call must be the same as the original. Therefore, those programs that rely on any particular behavior of these calls might misbehave. In other words, on Lisex 0.0, the behavior of some kernel call have been modified in such way that the response of any program relying on the old behavior could be notably different. For example, root could not always open any file because the new version of open will enforce the access controls considering root as any other user.

Some of these semantic changes are only design choices that could be modified (in fact this will be possible in GIDIS Trusted Linux) but most of them implements the essence of MLS security model.

The security features of Lisex 0.0 are the following (most of them are shown in the Manual del usuario y del administrador and others in the  Introducción a la seguridad de Lisex 0.0):

	ACL for each file and directory with the ability of including both users and groups. Each ACL has a list of owners of the file or directory instead of only one.
	Semantic modification of the "group" other on the permissions of files and directories. It is considered as the same as group All defined on Ms NT, that is, it represents all the users instead of the rest of users.
	The i-node structure of ext2 and VFS was altered.
	Some i-node operations were modified at ext2 and VFS level.
	The group root is equivalent to the user root. (i.e. all users in root group have super-user capabilities)
	New user and "group" secadm in charge of the administration of the MAC attributes.
	New access classes for files and directories were added.
	New access classes for users and process were added.
	Semantic modification to the following kernel calls:

	chdir demands read rights over the directory instead of execution right over it.
	chmod and chown cannot be executed over open files and also enforces ACL permissions.
	creat creates a new file with the same access class of the requesting process and checks MLS access over the parent directory as it would have been opened for reading and writing.
	execve takes execution as reading so it makes MLS checks.
	mkdir creates a new directory with the same access class of the requesting process and checks MLS access over the parent directory as it would have been opened for reading and writing.
	open add the MLS access controls and the extended DAC over all files open by each process including its binary executable itself and the dynamic libraries used by it.
	rmdir check for MLS writing access over the directory to be remove.
	setuid changes the identity of the process only if simple security properties and extended DAC properties are fulfilled.
	stat returns traditional information, but now inferred from the new ACL.
	unlink check for MLS writing access over the parent directory.

	aclstat returns all the data on the ACL of a file or a directory.
	acladd adds user or groups to a file or directory ACL as reader, writers or owners.
	chobjsc changes the access class of a file or directory, only can be called by members of the "group" secadm.
	chsubsc changes the access class of a user, only can be called by members of the "group" secadm.
	acldel removes users or groups from a file's or directory's ACL.
	oscstat returns the access class of a file or directory.
	ownerclose allows an owner of a file to close it even when it has been opened by another user.
	sscstat returns the access class of a user.

	The behavior of login was modified regarding the delivery of terminals.
	The implementation of capabilities (kernel 2.4.14) was removed from the file system.
	The program debugfs was modified to allow the edition of the Lisex 0.0 file system.
	The semantic of the execution permission (x) was modified on files and directories.

Features implemented inefficiently or inconveniently.

Lisex 0.0 implements the security upgrades only on the file system. This allows a particular type of Trojan horse to still be dangerous. A complete test over the whole system was not done; only the specification level test cases were generated and only a few test cases were executed at implementation level. The length of ACLs is fixed, configurable only with kernel re-compilation. The set of categories of access classes if of fixed length, configurable only with kernel re-compilation. Each category was implemented with one integer (of 32 bits), when each integer can be used to implement 32 different categories (one per bit). The security labels used by the system for the categories and levels are not human-readable. Changes to users' access classes is only possible by recompiling the kernel. These classes are loaded on system initialization; more precisely, they are hard-coded on the code of the main function of the kernel. No commands for modifying user's access classes where developed. The programs for listing the access classes or ACLs are rudimentary. The access class for root must be maximal with the only purpose of being able to deliver ttys on login time; this is for sure a security fault that must be removed in future versions. root can invoke a setuid to become any MAC security officer. This is also an important security fault due to the fact that any Trojan horse installed by the administrators have the ability to alter the access classes.

Many of these features will be re-implemented in the next version: GIDIS Trusted Linux.